

IN THE SPECIFICATION 



With reference to the published international application, 
i.e., WO 2004/046881, please amend/replace the below identified 
paragraph (s) as indicated, strikeout or double bracketed portions 
deleted, underlined items added: 



>*Page 5f, the first partial paragraph at line 10, please 
insert — of — after "RenderMan in terms" so as to now read as 
follows : 



RenderMan® is the name of a software program created and owned 

by Pixar that allows computers to render pseudo life-like digital 

images. RenderMan, a point-sampling global illumination rendering 

system and subject of U.S. Pat. No. 5,239,624, is the only software 

package to ever receive an Oscar® award from the Academy of Motion 

Picture Arts and Sciences. RenderMan clearly represents the current 

state of the art in pseudo-realistic point sampling software. On 

the other end of the spectrum, game consoles such as Sony 

PlayStation® or Microsoft X-Box® clearly do not exhibit the quality 

of realism found in RenderMan, but these hardware-based local 

illumination gaming appliances have a tremendous advantage over 

RenderMan in terms of speed. The realistic frames of animation 

produced by RenderMan take hours, even days, to compute, whereas 

the arcade-style graphics of gaming appliances are rendered at a 

rate of several frames per second. 

>*Page 11 and continuing on Page 12, the descriptions with 
respect to FIGS. 2 and 3 are to be switched, so as to now read 
as follows : 
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With reference to FIG. 3, like the artist via the viewing position 
[[60]] 22, the system 40 of FIG. 2 simulates the process of looking 
through a rectangular array of pixels into the scene from the 
artists viewpoint. Current methodology uses a ray 62 that starts at 
the viewing position 60 and shoots through a location within pixel 
50. The intersection of the ray with the pixel is called a point 
sample. The color of each point sample of pixel 50 is computed by 
intersecting this ray 62 with objects 64 in the scene. If several 
points of intersection exist between a ray 62 and objects in the 
scene, the visible intersection point 66 is the intersection 
closest to the origin of the viewing position 60 of the ray 62. The 
color computed at the visible point of intersection 66 is assigned 
to the point sample. If a ray does not hit any objects in the 
scene, the point sample is simply assigned a default "background" 
color. The final color of the pixel is then determined by filtering 
a neighborhood of point samples. 

2>Page 21f, line jf, please delete the second comma appearing in 
9/0^ that line, so as to now read as follows: 

Returning back again to the notion of point-sampling, and with 

reference now to FIGS. 6 (a) -(f), FIG. 6(a) represents a single 

pixel containing four scene objects, with FIGS. 6(b) -(f) generally 

showing a point-sampling algorithm at work in furtherance of 

assigning the pixel a single color. As should be readily apparent, 

and generally intuitive, the color of the pixel might be some kind 



of amalgamation (i.e., integrated value) of the colors of the scene 
objects. In FIG. 6(b), only a single point sample is used, and it 
does not intersect with any of the objects in the scene; so the 
value of the pixel is assigned the default background color. In 
FIG. 6(c), four point samples are used, but only one object in the 
scene is intersected; so the value of the pixel is assigned a color 
that is 75% background color and 25% the color of the intersected 
scene object. In FIGS. 6(d), 6(e) and 6(f), additional point 
samples are used to compute better approximations (i.e., more 
accurate representations) for the color of the pixel. Even with the 
increased number of point samples in FIG. 6(e), two of the scene 
objects are not intersected (i.e., spatial aliasing: missing 
objects), and only in FIG. 6(f) does a computed color value of the 
pixel actually contain color contributions from all four scene 
objects. In general, point sampling [[,] ] cannot guarantee that all 
scene objects contained within a pixel will be intersected, 
regardless of how many samples are used. 

ffaft ^Page 24, line Vf, please replace "William Walster, Global 

v^-. Optimization (publ . pending) " with — Eldon Hansen and William 
U/ walster, Global Optimization Using Interval Analysis . Second 
Edition — , so as to now read as follows: 

The present invention, in all its embodiments, abandons point 
arithmetic and point-sampling techniques altogether, and instead 
turns to an interval analysis approach. First invented and 
published in 1966 by Ramon Moore, interval arithmetic is a 
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generalization of the familiar point arithmetic. After a brief 
period of enthusiastic response from the technical community, 
interval arithmetic and interval analysis (i.e., the application of 
interval arithmetic to problem domains) soon lost its status as a 
popular computing paradigm because of its tendency to produce 
pessimistic results. Modern advances in interval computing have 
resolved many of these problems, and interval researchers are 
continuing to make advancements, see for example William Walster, 

Global Optimization — (publ. — pending) Eldon Hansen and William 

Walster, Global Optimization Using Interval Analysis. Second 

Edition ; L. Jaulin et al., Applied Interval Analysis ; and, Miguel 
Sainz, Modal Intervals . 



2>Page 28, line K^please delete "the" after "character," so 
as to now read as follows : 



An output of the interval consistency solvers is indicated as 
pixel data (i.e., the task of the interval consistency solvers is 
to quantitatively assign a quality or character to a pixel) . The 
pixel data output is ultimately used in image synthesis or 
reconstruction, vis-a-vis forwarding the quantitatively assigned 
pixel quality or character [ [the] ] to a display in furtherance of 
defining (i.e., forming) a 2-D array of pixels. For the 
parameterized system input of FIG. 11, a 2-D array of pixels, 
associated with a defined set of intervals, is illustrated. 



ft 
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>*Page 13, delete the first full f thereon beginning "FIG. 
20. . . " as follows: 

FIG. — 20 is a depiction ul importance filtering in the con-text 
of the importance function of FIG. — Hh- 

/} 

>*Page Jt47 in the first partial 5: 

at line 20 thereof , please insert reference numeral — 42— 
after "database" ; and, 

at line 24 thereof, please delete reference numerals "32" 
and "30", as follows: 

This grid technique is the real world analogy to the computer 
graphic process that forms the basis of modern day digital 
graphics. FIG. 2 shows the overall process of how a computer 
graphics system 40 turns a three dimensional digital representation 
of a scene 42 into multiple two-dimensional digital images 44. Just 
as the artist uses the cells 24 and 32 (FIG. 1) to divide the 
representation of an entire scene into several smaller and more 
manageable components, the digital graphics system 40 divides an 
image 4 4 to be displayed into thousands of pixels in order to 
digitally display two-dimensional representations of three 
dimensional scenes. A typical computer generated image used by the 
modern motion picture industry, for example, is formed of a 
rectangular array of pixels 1,920 wide and 1,080 high. In a 
conventional digital animation process, for example, a modeler 
defines geometric models for each of a series of objects in a 
scene. A graphic artist adds light, color and texture features to 

-6- 



plurality of interval consistency solvers. Operatively and 
essentially linked to the interval consistency solvers is a system 
input, exemplified in FIG. 10 by a series of generic parametric 
equations, each function having two or more variables, for example 
the arguments t, u, and v as shown, and as representatively 
illustrated in FIG. 11, wherein the "system" is a sphere, the x-y-z 
functions being parameterized in t, u, v. It is to be understood 
that the system need not be limited to parametric expressions, 
which have the greatest utility and are most 
challenging/problematic, other geometric primitives, or alternate 
system expressions are similarly contemplated and amenable to the 
subject methodology and process as is to be gleaned from the 
discussion to this point. For example, the system can similarly 
render strictly mathematical formulae selectively input by a user, 
such as those describing polygons, and bezier surfaces, the later 
being the singular focus of RenderMan. 



The solver, more particularly the most preferred components 
thereof, namely screen, pixel, coverage, depth, and importance, are shown 
in relation to the input (i.e., dim and system), callbacks (i.e., 
shader) , and output (i.e., pixel data and display). The 
interrelationships between the individual most preferred elements 
of constituents of the solver, and the general temporal hierarchy 




>*Page 23, in first partial SI thereon, at line 8 thereof, 
please replace "FIG. 12" with — FIG. 13 — as follows: 
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The coverage solver, as detailed in FIG. 16, essentially 

replicates the iterations of screen, based upon a user defined limit 

epsilon (eps) . Coverage, as the name suggests, seeks to delimit, via 

the retention of contributing t, u, v aspects based upon the user 

specified chop area "eps," those portions (i.e., areas) of the 

object surface within the pixel subunit (again, aee FIGS. 19(b) 

19(f) (again, see FIGS. 19 (b) -19 (f ) ) . Upon ascertaining the values 

associated with the x-y space or area, they are added or compiled 

to provide or define the total coverage of the object surface 

(i.e., a mapping of the entire x-y space). At this point, analysis, 

more particularly processing, in x-y space is complete. The next 

procedural task is a consideration of depth (i.e., assessment of 

Z(t, u, v) of the parametric system with a fixed or set x and y) . 
?/ 

>Page J^T, in the first partial 1 thereon at line 4 thereof 
(i.e., in the last 11 at page 31 beginning "The depth 
solver..."), please replace "(z depth)" with — z depth, i.e., 
set to an interval at an infinite distance from the viewer — 
as follows: 

The depth solver, as detailed in FIG. 17, is essentially doing 
the job of FIG. 17(a) . More particularly, depth initially ascertains 
where in the z dimension, ultimately from the image plane (see FIG. 
4 camera space), does the object surface, heretofore defined in x, 
y, t, u, v aspects, first appear or reside (i.e., in which depth 
cell), and thereafter step into space, via iterative cells, until 
the x, y, t, u, v object surface is no longer present in a cell 
(i.e., cell X of FIG. 17(a)). In furtherance thereof, the depth 
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variable, more accurately, depth function, is initialized for all 

depth space, namely set to the infinite interval (z depth) - (z 

depth, i.e., set to an interval at an infinite distance from the 

viewer. Thereafter, t, u, v, contraction begins in the depth field 

(zO) . Subsequently, there is a trivial accept/reject query as to 

whether there is in fact a depth component of the x-y 

parameterization, with searching commencing thereafter (z search) . 

For each depth cell, the importance solver (i.e., the t, u, v, 

chopper wherein a set inversion is executed in t, u, v so as to 

contract same) is called upon, and it is necessary to next assess 

if the shader was invoked. If the shader is invoked (i.e., a first 

visible root is identified) , the output of the shader are 

accumulated into the importance sums and the depth parsing 

continues in furtherance of accounting for all z components of the 

x-y object surface, if not, steps, on a cell by cell basis are 

"walked off.'' Although the parsing or chopping of z space has been 

described as a serial or loop type progression, its is certainly 

amenable to recursive splitting, as the case of the x-y space. 

Jffr/f >Page^3«7 in the first partial \ thereon beginning at line 4 

/ thereof, please delete and in the present setting, 

U/ff/^J illustrated in FIG. 20" as follows: 

The importance solver, as detailed in FIG. 18, when called, 

essentially completes a set inversion in t, u, v, that is to say, 

for the smallest x, y, z (i.e., each specific z cell for, or in, 

which an object surface element x-y resides), t, u, v are to be 
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